Chapter 3
Thinking in Operations
"Good architectures rarely begin by asking how something is done. They begin by describing what should happen."
Why This Chapter Exists
Software naturally encourages procedural thinking.
An object receives a request.
A function executes.
State changes.
The work is complete.
While perfectly valid, this perspective often causes systems to become tightly coupled over time.
Every object must know who performs the work.
Every subsystem gradually accumulates knowledge about neighboring systems.
The Cube Framework deliberately approaches this problem differently.
Instead of modeling execution first, it models intent.
This distinction introduces one of the most important concepts in the framework.
The Operation.
Intent Before Execution
Imagine the following request.
A player assembles a new weapon.
At first glance this appears to be a simple action.
In reality, multiple independent systems must participate.
Definitions must be collected.
Compatibility must be validated.
Assets may need to be resolved.
Runtime data must be assembled.
Networking may eventually synchronize the result.
Gameplay may finally interact with the completed object.
Although the player performed a single action, the architecture performed many.
The request itself therefore deserves to exist independently from its execution.
This request is an Operation.
What Is an Operation?
An Operation is a typed request that describes architectural intent independently of its execution.
It answers the question:
What should happen?
It intentionally avoids answering:
How should it happen?
Every Operation contains only the information required to describe the requested action.
It does not execute the request itself.
Instead, it is passed to the framework system responsible for fulfilling it.
This distinction allows architectural responsibilities to remain clearly separated.
Operations describe intent.
Framework systems own execution.
Operations Are Architectural Contracts
One useful way to understand Operations is to think of them as contracts.
An Operation promises that a particular outcome is requested.
It does not promise how that outcome will be achieved.
This allows implementations to evolve without changing the architectural language.
Validation may improve.
Runtime Assembly may change.
Networking may become more sophisticated.
The Operation itself remains stable because the intent has not changed.
Why This Matters
Without Operations, higher-level systems frequently become responsible for orchestration.
Gameplay begins coordinating validation.
Validation begins coordinating assembly.
Assembly begins coordinating networking.
Responsibilities slowly merge.
Operations prevent this.
Each subsystem simply fulfills the portion of the request that belongs to its responsibility.
Nothing more.
An Example
Consider a player assembling a modular weapon.
From a gameplay perspective, this appears to be a single action.
Within the Cube Framework, however, that action is represented as one architectural Operation that moves through multiple systems.
Gameplay
│
▼
Operation Request
│
▼
Operation Type
│
▼
Responsible System
│
▼
Execution
Notice that the Operation itself performs no work.
It simply represents the architectural intent.
Each subsystem contributes only the responsibility that belongs to it before passing the Operation to the next stage of the Runtime Pipeline.
Operations Are Not Commands
Although Operations resemble commands, the Cube Framework intentionally distinguishes the two.
Commands often imply immediate execution.
Operations merely express architectural intent.
Execution belongs to the systems responsible for fulfilling that intent.
This distinction becomes increasingly valuable as the framework continues expanding.
A Stable Architectural Language
One of the greatest advantages of Operations is consistency.
Regardless of how many systems participate...
Gameplay speaks the same language.
Networking speaks the same language.
Runtime speaks the same language.
Every subsystem understands the request.
Each responds according to its own responsibility.
Architecture becomes collaboration instead of control.
Design Note
The Cube Framework treats Operations as architectural concepts rather than implementation details.
Whether an Operation is represented by a class, a function or another mechanism is ultimately an implementation choice.
Its architectural purpose remains the same.
Operations describe intent.
Subsystems fulfill it.
Framework Law III
Operations describe intent. Systems own execution.
The more clearly these responsibilities remain separated, the easier the framework becomes to extend.
Revision History
Version 1.0
Initial publication.